Connection Pooling
Connection pooling is a technique where a client application maintains a set of pre-established Redis connections and reuses them instead of creating a new connection for every request.
Without pooling:
- Application opens a new TCP connection → sends a request → closes it
- High overhead
- Slow
- Causes connection churn on Redis server
- Leads to TIME_WAIT and socket exhaustion
With pooling:
- A pool of persistent Redis connections is created once
- Each request picks an idle connection
- Returns it to the pool after use
This significantly improves:
- Latency
- Throughput
- Server stability
- Concurrent request handling
Why Connection Pooling Improves Performance
Opening/closing a TCP connection is expensive:
TCP overhead includes:
- Handshake (SYN → SYN-ACK → ACK)
- TLS handshake (if SSL enabled)
- Kernel allocation for sockets
- Redis authentication (AUTH)
- Redis handshake (HELLO/RESP negotiation)
All of these add milliseconds per operation.
If an app performs 1,000 operations/sec, but each requires creating a connection, the overhead becomes huge.
Connection pooling eliminates all this by keeping connections alive.
Redis Server Connection Limits
Redis is fast with commands, but slow to handle thousands of new connections per second.
Default connection limit:
maxclients 10000
If your application does not pool connections, it may exhaust maxclients under load.
Pooling minimizes client count.
How Connection Pooling Works (Architecture)
Application
├── Worker Thread A ---┐
├── Worker Thread B ---|--> Connection Pool (10–100 connections)
├── Worker Thread C ---┘
└── Worker Thread D → Redis Server
Workers borrow connections from the pool → execute → return connections.